Commissioning a penetration test worth paying for
We scope the test, help you choose a qualified provider, read the report on your side and track every finding to the provider's retest.
- Who tests
- A provider you contract directly
- Providers compared
- Three that you pick
- In Saudi Arabia
- Provider checked on NCA's public list of registered providers
- Outside Saudi Arabia
- Provider licensed or accepted where you operate
- Delivery
- Remote, on site in Saudi Arabia where needed
A penetration test is only as good as its scope. We write the scope and rules of engagement, help you compare providers on method rather than price, read the report with you, and turn the findings into a fix plan with owners and a retest date. The test itself is carried out by a qualified provider that you contract directly.
- 01 Call
- 02 Scope
- 03 Read
- 04 Register
- 05 Documents
- 06 Plan
Commissioning a penetration test worth paying for sits at step 4 of how an engagement runs. You receive the register.
How penetration tests get wasted
The money is rarely lost during the test. It is lost before it starts and after the report lands.
Before: the scope is written by the firm selling the test, so it covers what they sell. "External test, three IP addresses" while the customer portal runs on a different host. Test accounts arrive on day three of a five-day window. The staging environment runs an older version than production. Nobody told the hosting provider, whose terms may require notice.
After: the report lists sixty findings, fifty of them informational, sorted by the tester's severity rather than by what matters to you. Fixes are marked done in an email. Nobody retests. Next year's report repeats this year's.
And sometimes the thing sold as a penetration test is an automated scan with a cover page. Asking for a sample report before you sign catches that.
What we do at each stage
Nine stages, from the reason you are testing to the provider's retest. The provider does the testing; the work either side of the test window is ours.
| Stage | What we do | What you hold |
|---|---|---|
| Question | Pin down why you are testing: a customer requirement, an ECC control, a new release, an insurer. | A one-page objective |
| Scope | List the exact targets, the tester's starting point, the accounts, the environment and the exclusions. | The scope document |
| Rules of engagement | Windows, source addresses, forbidden actions, data handling, stop conditions, and contacts on both sides. | The rules of engagement |
| Choose | Send the scope to three providers you pick, then compare the answers on method, people and sample reports. | The comparison matrix |
| Prepare | Accounts created and tested, the hosting provider notified where its terms require it, backups confirmed, contacts briefed. | The test readiness checklist |
| During | The provider tests. We answer its scope questions and relay any critical finding to your system owner the same day. | A contact log |
| Read | Walk through the report with you and your IT team, recheck severity against your context, and group findings by cause. | The findings register |
| Fix | Owners and dates for each cause, not each finding. | The fix plan |
| Retest | The provider retests the fixed items, and we update the register from its confirmation. | The closure register and the provider's retest confirmation |
The file you end up holding
The test objective and scope document
One sentence on why you are testing, then every target typed exactly, the tester's starting point, the accounts, the environment, and each exclusion with its reason.
The rules of engagement
Windows with the time zone, source addresses, forbidden actions, data handling, stop conditions and named contacts, ready for both parties to sign.
The provider comparison matrix
Three proposals side by side on method, the people who will test, days per target, a redacted sample report, data handling and retest terms. Price is the last column.
The test readiness checklist
Accounts created and tested, the hosting provider notified where required, backups confirmed and contacts briefed, all before the window opens.
The findings register
Every finding with its system owner and the tester's severity, beside a severity rechecked against your business. A critical on a lab server with no data may matter less than a medium on the page that takes payments.
The fix plan
Written against causes, with an owner and a date for each. Fourteen missing patches are one finding about the patching process, not fourteen tasks.
The closure register
Each cause marked closed against the provider's retest confirmation, so what was found, fixed and retested sits in one place.
Comparing providers on what changes the result
Five things change the result of a test, so they are compared first. Price comes after them, because a cheaper proposal with half the testing days is usually half the test.
- 01
Method
How much of the testing is manual, and which published method it follows, such as the OWASP Web Security Testing Guide or NIST SP 800-115. We ask each provider how it would test one of your own features.
- 02
People
Who will actually test, and what qualifications they hold. The salesperson is rarely at the keyboard.
- 03
A redacted sample report
From a real engagement. It tells you more than the proposal does, and it is where an automated scan with a cover page shows itself.
- 04
Data handling, retest terms and critical findings
Where screenshots of your data are kept and when they are deleted, whether a retest is included, and how fast they call you about something serious.
- 05
Standing
In Saudi Arabia, the provider should be on NCA's public list of registered providers. Check the list at the time you contract. Elsewhere, the provider must be licensed or accepted in your jurisdiction; some markets use accreditation schemes such as CREST.
- 06
Price
Compared last, and against days per target. Two proposals for the same scope at very different prices usually differ in days, and fewer days means less of your application tested.
A first report for a customer's review
A software company sells a web platform to enterprise customers in Saudi Arabia and the UAE. A new customer's vendor security review asks for a penetration test report less than a year old, and the company has never had one.
The customer's real question is whether its data can be reached by other tenants or from the internet. That points to an authenticated web application and API test, plus a cloud configuration check. The scope lists the application URL, the API version, two accounts per role in two separate test tenants, and a staging environment refreshed from production with personal data masked. Denial-of-service testing is forbidden; the window is night-time.
Three providers the company selects receive the scope. One proposal turns out to be largely automated, which its sample report confirms, and the company contracts another.
The report's findings group into two causes: missing authorisation checks in one API module, and security headers never configured. The fix plan names two developers and a date, and the provider retests. The company holds the scope, the rules of engagement, the comparison matrix, the fix plan, the closure register and the provider's retest confirmation, which is what its customer asked to see.
Start from the question, then pick the test
Buyers ask for "a pen test". The useful question is what you need to find out, and each test answers a different one. A provider or your own IT team runs each of them; our part is matching the test to the question and writing its scope.
Can someone on the internet get into our systems?
That is an external infrastructure test, run against your internet-facing addresses and hostnames.
- It will not tell you anything about what a logged-in user can do
Can one customer see another customer's data?
That is an authenticated web application test, run with two accounts from different customers. Without the second account, that flaw is very hard to find.
- The scope needs two accounts per role, in two separate customer accounts
- It will not tell you whether the server underneath is patched
Is the API behind our mobile app safe?
That is an API test against the documented endpoints and the undocumented ones.
- It will not tell you how the app stores data on the phone
What can an attacker do once inside the office network?
That is an internal infrastructure test. Whether anyone would notice is a different question, answered by a red team exercise from a specialist team, and only once the basics on these tabs are in place. A red team exercise against an organisation without an asset list mostly proves that it has no asset list, and we say so before you buy one.
- It will not tell you whether anyone would notice
Would staff hand over a password?
That is a social engineering exercise, agreed in writing with HR before it starts.
- It will not tell you whether your systems are technically sound
Which known vulnerabilities do we carry?
That is a vulnerability scan, run by your IT team or a provider. It is not a penetration test. Most first tests should be the second or third tab: between customers, or behind the app.
- It will not tell you whether any of them can actually be exploited
Questions buyers ask first
Why not let the testing firm write the scope?
It can, and many do. The difficulty is that the firm selling the test is then deciding what gets tested. A scope written on your side starts from what you need to know.
How many providers should we ask?
Three is usually enough to see real differences in method. Fewer and you have nothing to compare; more and the comparison becomes the project.
How often should we test?
After any major change to a system, and at an interval your own policy sets. If you are in ECC scope or a customer contract sets a frequency, that sets the minimum.
What happens if the tester finds something critical in the window?
The rules of engagement already say: a same-day phone call to a named person. We relay it to your system owner, who decides whether to fix it immediately or let testing continue around it.
Who retests the fixes?
The provider that found the issue. That keeps the confirmation independent of the people who planned the fix. We update the register from the provider's retest confirmation, cause by cause.
We are outside Saudi Arabia. Can you still help?
Yes. The work is remote and in English. The provider must be licensed or accepted in your own jurisdiction, and that is checked as part of the comparison.
Read before you commission
How to scope a penetration test
The question, the targets, the starting point and the rules, with a checklist and a sample scope paragraph.
Read moreGuideWhat a good report contains
The nine parts of a good finding, and twelve lines to hold a sample report against before you sign.
Read moreGuideFrom report to fix plan
Re-rating severity, grouping findings by cause, and booking the retest before the plan is signed off.
Read moreGuideScan or penetration test
Which test answers which question, and the order most organisations should buy them in.
Read moreITF DigitalWhen the fixes are in software
ITF Digital builds applications, and can work on the causes a report traces back to application code.
Read morePart of one system
Every division keeps records to the same standard, so the second one you need works the way the first one did.
Start with the scope
A scoping session starts from why you are testing and ends with the targets, the starting point and the accounts the tester will need, written down.