What information must be provided in advance for a pentest?

  1. Home
  2. Frequently asked questions
  3. What information must be provided in advance for a pentest?

The information you provide in advance differs per test type. This page describes per assessment type what information DongIT needs for an efficient pentest. For broader preparation, see the FAQ on how you prepare for a pentest.

General information (for all assessment types)

For every pentest we need this base information:

  • Contact person. Name, email address and phone number of your primary contact person, available by phone during the test period.
  • Decision-making authority. Who in your organization can immediately decide on temporary mitigation for critical findings (for example disabling a feature).
  • Test window. Which days and times are test activities permitted. Are there blackout periods (for example peak moments or maintenance windows)?
  • NDA or data processing agreement. Signed version before the pentest starts.

Web application pentest

  • URLs. Of the acceptance or test environment. Production URL for reference.
  • Test accounts. Preferably a single superuser who can create all user roles. Otherwise at least two accounts per user role.
  • Multi-tenant setup. If multiple organizations can log in through the application: preferably a cross-tenant superuser, otherwise administrator accounts for at least two organizations (so tenant isolation can be tested).
  • Documentation. User documentation, functional description, integrations with external systems and any customization.
  • Approach-specific. For white-box: SSH or FTP access to the acceptance environment, access to source code, complete architecture documentation. See the FAQ on differences between black-box, grey-box and white-box.

Mobile app pentest (iOS and Android)

  • iOS test app. Access via TestFlight or signed IPA file.
  • Android test app. Signed APK file or access via Firebase App Distribution.
  • Test accounts. As for web applications: preferably superuser, otherwise at least two accounts per role.
  • Backend API endpoints. URLs of the test backend and API documentation.
  • Certificate pinning. Instructions for disabling in a test build, or a separate build without pinning for the duration of the test.
  • Anti-tampering and root/jailbreak detection. Instructions for test environment configuration where these detections are disabled.
  • Postman collection. For the backend API with valid requests.

API pentest (REST, GraphQL, SOAP)

  • API base URLs. Of the test or acceptance environment.
  • API specification. OpenAPI/Swagger specification for REST, GraphQL schema (introspection endpoint) or WSDL for SOAP.
  • Postman collection. With valid example requests for all endpoints. See www.postman.com.
  • Authentication. API keys, OAuth credentials or client certificates for test accounts.
  • Rate-limiting policies. Documentation of rate limits and throttling settings during the test.
  • Multi-tenant scoping. How organizations are separated and which accounts are needed to test isolation.

Cloud pentest (Azure, AWS, GCP)

  • Read-only console access. To the relevant tenant, subscription or project.
  • IAM roles for pentester accounts. Temporarily scoped with the minimum permissions needed.
  • Resource inventory. IaC configurations such as Terraform, Bicep or CloudFormation are ideal.
  • Architecture diagram. Overview of how services connect to each other.
  • Provider approval. For AWS where certain services (DNS, RDS) require additional approval. We arrange these approvals during scoping.
  • Business context. Which resources are critical and where does data reside?

Source code review

  • Repository access. Read-only access to the Git repository (GitHub, GitLab, Azure DevOps, Bitbucket).
  • Target branch. Which branch is the reference (main, master, develop, release)?
  • Architecture documentation. Data flow diagrams, dependency graphs and overview of external integrations.
  • Build instructions. To build the application locally and resolve dependencies.
  • Third-party dependencies list. Package.json, requirements.txt, pom.xml or similar.
  • Focus areas. Which modules are critical and deserve extra attention?

Other assessment types

For other assessments we work with type-specific scoping. Contact us for the exact requirements:

  • Network pentest (external). IP ranges, hostnames, hosting provider contact, test window.
  • Network pentest (internal). VPN access or jump host, network diagram, AD/LDAP accounts.
  • Red team assessment. Objectives, scope definition, escalation contact, MFA status, signed legal authorization.
  • Phishing simulation. Target group list, recent email templates for authenticity, whitelisting at spam filters.
  • OT pentest. OT network diagram, type of systems (SCADA, HMI, PLC), test window, emergency stop procedure.

Not sure what information to provide for your specific scope? Contact us for a complimentary scoping conversation, or view our pentest packages.