Detailed answers to common PentestHint client questions about scoping, authorization, access, delivery, reporting, remediation, retesting, confidentiality and AI automation work.
Frequently Asked Questions
How does an engagement begin?
An engagement usually begins with a short discussion about the business objective, systems involved, expected outcome, timeline and stakeholders. PentestHint may ask whether the need relates to VAPT, application testing, API security, cloud review, infrastructure assessment, hardening, security architecture, secure development, AI automation, training or certification support. The first conversation should not include passwords, private keys or sensitive production data. It should provide enough context to decide what type of scope is appropriate.
What information is required for scoping?
Useful scoping information includes asset type, number of applications or APIs, user roles, cloud provider, approximate IP ranges, testing environment, preferred timeline, compliance or customer assurance needs, reporting expectations and any known operational constraints. For development or automation work, useful information includes workflow description, data sources, users, approvals, integrations and expected deliverables. The goal is to understand boundaries before proposing effort.
How is the assessment boundary determined?
The boundary is determined through the agreed asset list, test accounts, IP ranges, URLs, APIs, cloud accounts, environments, exclusions and rules of engagement. Boundaries may also include time windows, rate limits, fragile systems, third-party services and escalation contacts. A clear boundary protects production systems and helps prevent findings from becoming too broad or unactionable.
How are assumptions and exclusions documented?
Assumptions and exclusions should be written into the scope or engagement notes. Examples include unavailable source code, third-party systems outside authorization, limited user roles, production restrictions, unauthenticated-only testing or cloud read-only access. Documenting assumptions helps readers understand what the final report does and does not prove.
Is written authorization required?
Yes. Written authorization is expected before security testing begins. It protects the client, the assessment team and any third-party provider involved. Authorization should define what may be tested, when activity can occur, who can be contacted during issues and what actions are excluded. Unauthorized testing is not supported.
What access may be needed?
Access depends on scope. Web and API assessments may need test accounts, role descriptions, API collections or documentation. Cloud reviews may need read-only access. Infrastructure assessments may need VPN or approved scanning ranges. Source code reviews may need repository access. AI or development work may need sample data structures, APIs, non-production environments and architecture notes. Least-privilege access is preferred.
Can black-box and authenticated testing both be performed?
Yes, if included in scope. Black-box testing reviews what is visible with minimal knowledge, while authenticated testing helps validate role behavior, access control, business logic and deeper application behavior. Many meaningful web and API risks require authenticated testing because they occur after login or across user roles.
How are credentials and secrets handled?
Credentials and secrets should be shared through approved secure channels, limited to the required scope and rotated or disabled after the engagement where practical. Do not submit production passwords, API keys, private keys or confidential datasets through the general contact form. If sensitive access is required, agree on a secure handoff method first.
How are project contacts established?
The client and PentestHint should identify primary technical and business contacts before work begins. Contacts help with access issues, urgent observations, reporting questions, remediation discussions and closure. Clear ownership prevents delays when a finding needs context or an environment blocks testing.
How are critical observations escalated?
Critical observations can be escalated through the agreed communication channel before the final report if the scope requires early notification. The escalation should include enough context for the client to triage risk without exposing unnecessary sensitive detail through insecure channels.
Can work be performed remotely or onsite?
Many application, API, cloud, AI, development and external assessment activities can be performed remotely with approved access. Onsite work can be discussed where the environment, infrastructure, wireless testing, stakeholder workshops or operational constraints make it useful. PentestHint supports remote and onsite security assessments where applicable, without claiming physical offices in every location.
How is operational disruption minimized?
Disruption is minimized through scope definition, test windows, rate limits, safe payload choices, exclusions, communication channels and careful handling of fragile systems. No security test is entirely risk-free, so planning matters. Production testing should be handled with clear boundaries and client awareness.
What does the final report include?
A security report may include executive summary, scope, methodology, findings, affected assets, evidence, severity, business impact, technical explanation, remediation guidance and retest status where included. For consulting or development work, deliverables may include architecture notes, workflow maps, implementation notes, security recommendations and handover documentation.
Are executive and technical summaries available?
Yes. Executive summaries help business stakeholders understand priority, impact and decision points. Technical summaries help developers, IT teams and security owners reproduce issues and plan remediation. The exact report format depends on the engagement type and agreed deliverables.
Is remediation guidance included?
Remediation guidance is typically included for assessment findings and review observations. Guidance may cover code changes, configuration updates, access-control fixes, patching, logging, hardening, architecture improvements or process changes. PentestHint can also discuss findings with relevant teams so remediation is practical.
Can findings be discussed with development or infrastructure teams?
Yes. Finding walkthroughs can help teams understand reproduction steps, evidence, impact and fix direction. This is often useful for web, API, cloud, infrastructure, Microsoft 365, Active Directory and hardening work where multiple owners may be involved.
Is retesting available?
Retesting is available where included in scope or requested separately. It helps confirm whether remediated findings are fixed, partially fixed or still open. Retesting should use the original evidence and expected remediation behavior as the reference point.
How are remediated findings validated?
Remediated findings are validated by repeating the relevant check, reviewing configuration or confirming that the vulnerable behavior is no longer reproducible. The retest result should document fixed, not fixed, partially fixed or not retestable status with clear notes.
What closure documentation may be provided?
Closure documentation may include retest summary, final status, residual risks, handover notes, remediation ownership, next-step recommendations or management summary. The goal is to leave stakeholders with a clear understanding of what changed and what still needs attention.
How is evidence handled?
Evidence is handled as sensitive engagement information. It should be collected only to support the agreed work and shared through appropriate channels. PentestHint does not publish screenshots, reports, vulnerabilities, client architecture or private findings without explicit approval.
Can an NDA be used?
Yes. An NDA can be used before sensitive information is shared. The NDA may cover scope details, access, reports, findings, architecture, source code, business processes and any other information agreed by the parties.
Are client details published?
Client details are not published unless approved. The Clientele page uses a central editable data source and avoids invented claims about services delivered to specific organizations. Security confidentiality is more important than public logo display.
How long is engagement data retained?
Retention should be discussed according to the engagement, legal requirements, client policy and operational needs. If a specific retention period is required, it should be documented before or during the engagement rather than assumed.
Who owns custom source code and documentation?
Ownership depends on the commercial agreement and project scope. It should be clarified before delivery begins. Handover should include relevant documentation, deployment notes, assumptions and maintenance expectations where applicable.
How are APIs secured?
Secure API work considers authentication, authorization, input validation, rate limiting, error handling, logging, secrets handling and documentation. API security testing can be included where the API needs validation beyond implementation.
Where are human approval gates used?
Human approval gates are used where automated actions carry business, security, privacy or operational risk. Examples include sending external communication, modifying production records, exporting sensitive data or triggering high-impact workflows.
How are AI outputs evaluated and monitored?
AI outputs should be evaluated with sample cases, edge cases, review feedback and failure tracking. Monitoring should capture useful operational signals while avoiding unnecessary sensitive data collection. Generated output should be reviewed where errors could affect business or security decisions.
