Scoping Questionnaire
Completed by the client before Verfend prepares a proposal. It tells us what to look at, how, and within which limits. Nothing is tested on the basis of this form alone.
1. How to use this form
1.1 Answer what you can and leave the rest blank; gaps are covered in the scoping call. Approximate figures are fine.
1.2 Testing begins only after the Service Agreement (Document 03) and the written Authorisation to Test (Document 04) are both signed. Please do not send passwords, keys or tokens with this form; access is provisioned later through a secure channel (Document 05).
2. Organisation and contacts
| Field | Details |
|---|---|
| Legal name of organisation | legal name |
| Trading name (if different) | trading name |
| Registration number (CNPJ / VAT / company number) | registration number |
| Registered address and country | address |
| Decision-maker (name, role, email) | name, role, email |
| Technical contact (name, role, email, phone) | name, role, email, phone |
| Emergency contact during testing (name, phone, hours reachable) | name, phone, hours |
| Preferred language for the report | ☐ English ☐ Portuguese (BR) ☐ Other: language |
3. What prompted this request
3.1 Tick all that apply.
- ☐ Received a security notice or report (from Verfend or a third party)
- ☐ Launch or major update of a product
- ☐ Compliance requirement (☐ LGPD ☐ GDPR ☐ Other: standard)
- ☐ Customer or partner requirement (e.g. vendor questionnaire)
- ☐ Security incident or suspected incident
- ☐ Routine periodic review
- ☐ Other: details
3.2 If a notice or report was received, please attach it or summarise it: summary
4. Assets to be considered
4.1 One row per system; add rows as needed. Only assets named in the Authorisation to Test (Document 04) are tested.
| # | URL / hostname / IP | Purpose | Environment | Technology (stack, framework, CMS) | Hosting provider | Approx. users | Handles payments? | Personal data? |
|---|---|---|---|---|---|---|---|---|
| 1 | asset | purpose | ☐ Prod ☐ Staging | technology | provider | number | ☐ Yes ☐ No | ☐ Yes ☐ No |
| 2 | asset | purpose | ☐ Prod ☐ Staging | technology | provider | number | ☐ Yes ☐ No | ☐ Yes ☐ No |
4.2 Are there APIs, mobile back-ends, admin panels or internal tools behind these assets? details
4.3 Which assets are business-critical (an outage would stop sales or operations)? details
5. Preferred access model
- ☐ External (black-box) — only what is reachable from the internet, no accounts. Closest to a real attacker; sees little of what sits behind a login.
- ☐ Grey-box with test accounts — you provide a dedicated test account per user role. Recommended for most web applications.
- ☐ White-box with source and staging — you provide read-only source access and a staging environment. Deepest coverage; best before a launch or after a serious finding.
- ☐ Not sure — please advise in the proposal.
6. Constraints
| Topic | Your answer |
|---|---|
| Preferred testing window (dates, days, hours) | window |
| Your time zone | time zone |
| Blackout dates (releases, campaigns, peak periods) | dates |
| Rate limits we must respect | limits |
| WAF, CDN or bot protection in front of the assets (vendor; can tester IPs be allowed through?) | details |
| Third-party components involved (payment gateways, SaaS, identity providers) | details |
| Systems or paths that must NOT be touched | details |
| Staging environment available for intrusive checks? | ☐ Yes ☐ No ☐ Partially: details |
| Do your hosting or cloud terms permit security testing? | ☐ Yes ☐ No ☐ Unknown — please check |
6.1 Denial-of-service and stress testing are excluded by default. Social engineering is excluded unless separately authorised.
7. Previous assessments and known issues
7.1 Last security assessment: when, by whom, what type? details
7.2 Open findings or known weaknesses you already plan to fix? details
7.3 Security incidents in the last 24 months? ☐ Yes ☐ No — if yes, briefly: details
8. Desired outcome and deadline
8.1 What would make this engagement a success for you? (a validated finding list, a report for a customer, closed findings before launch…) details
8.2 Which service are you leaning towards? ☐ Validate (finding validation) ☐ Assess (security audit) ☐ Resolve (vulnerability remediation + retest) ☐ Monitoring (ongoing monitoring) ☐ Please advise
8.3 Hard deadline for the report, if any: date — reason: reason
8.4 Who will receive the report? names, roles
9. Budget range (optional)
☐ Under amount ☐ amount – amount ☐ Above amount ☐ Prefer to receive a proposal first
Currency: ☐ BRL ☐ EUR ☐ USD ☐ Other: currency
10. Ownership confirmation
10.1 I confirm the organisation owns or is authorised to permit testing of the assets listed in section 4, and that I am entitled to make this statement on its behalf.
10.2 I understand that no testing takes place until the Service Agreement (Document 03) and the Authorisation to Test (Document 04) are both signed.
Name: ______________ Role: ________ Organisation: ______________ Date: ________
Verfend · Independent Security Operations · email · website · Document 01 v1.0 · date