Key takeaways
- A penetration test is sold in tester days, and those days start whether or not the tester can log in.
- Give every role two accounts with data of its own: horizontal authorisation flaws cannot be found with a single user per level.
- Decide the WAF question before the test. Testing through the edge shows what an attacker meets today, testing behind it shows what your developers have to fix.
- Name one technical contact who can answer inside a working day, and one route for a critical finding that does not wait for the report.
- Hand over the API specification, the roles matrix and the previous report. What the tester is not told, they spend the first day discovering.
The days you paid for start on day one
A penetration test is sold as a number of tester days against a scope you agreed in advance. Those days begin on the start date whether or not the tester can reach the host, log in as the roles the scope names, or find out which of your three environments you meant. Time spent waiting for a password reset is time not spent on the application, and it is not added back at the end of the week.
Readiness has a short definition. On the morning of day one the tester can reach every target named in the scope, authenticate as each role that appears in it, and get an answer to a question before the day ends. Scoping decided what gets tested; readiness decides how much of that scope is actually reached. A scoped penetration test is bounded work, so anything that eats an afternoon comes out of the testing somewhere. What follows is the list of things that eat afternoons.
Accounts: one per role is not enough
Authorisation is where manual testing earns its price, and it cannot be tested with one account per role. Horizontal access, meaning one user reading another user's records at the same privilege level, needs two accounts at that level with data belonging to each of them. Vertical access needs one account at every level the application defines, including the administrative one. The OWASP Web Security Testing Guide sets out the authorisation tests in exactly this shape, and every one of them assumes the accounts already exist.
Then make the credentials survive the week. An account that locks after three failed attempts will lock, because testing involves failed attempts. Second-factor enrolment bound to a phone in a drawer stops the test at the first login, so bind it to a device or address the tester controls, or disable it on the test accounts and record that in the report. Passwords should not expire inside the test window. Each account should already own the records it is meant to own, because an account with nothing behind it proves nothing about access control: there is nothing there for the other account to fail to reach. Provision them the way a web application test will use them, as separate people with separate data.
The matrix below is an illustration rather than a customer's, and it is the level of detail worth writing down before the test.
| Account | Role | Owns | Prepared so that |
|---|---|---|---|
| test-user-a | Standard user | Two orders, one saved payment method | Second factor is enrolled to a tester-controlled address |
| test-user-b | Standard user | Two orders under a different customer record | There is data for test-user-a to be denied |
| test-mgr-a | Manager | Approval rights over test-user-a's orders | Vertical checks run in both directions |
| test-admin | Administrator | Tenant configuration | It is a dedicated account, not a shared live one |
Which environment, and how honest it is
Production or staging is a real decision with a wrong answer available in both directions. Production is honest and carries consequences: real customers, real data, and changes you cannot undo. Staging is safe and can mislead, because it may run a different build, a different identity provider, a fraction of the data or no edge protection at all. A finding on staging transfers to production only where the two agree about the things the finding depends on, so the environment question is really a question about how they differ.
Write those differences down before the test rather than discovering them in the debrief. If staging is the target, confirm it runs the build you are about to ship, that roles and permissions match, and that it holds enough data for authorisation and rate limiting to behave the way they will in production. Take a restore point. Agree a change freeze for the test window, or accept that a deployment on Wednesday afternoon can invalidate what was found on Wednesday morning.
Settle the edge question in the same conversation. Testing through the WAF measures what an attacker meets today. Testing from an allowlisted address measures what the application does without it, which is the part your developers have to fix. Both are legitimate and they answer different questions. NIST SP 800-115 puts this in planning rather than execution, and the reason is practical: a firewall change raised on day two costs a day, while the same change raised a week early costs an email.
The documents that shorten the test
Four documents change how the first day goes. An API specification, ideally the file the service already publishes internally, so the tester works through your endpoints instead of the ones they can guess. A roles and permissions matrix, because a tester cannot report broken authorisation without knowing what correct authorisation was supposed to be. An architecture or data flow diagram, which is what turns a list of hosts into an understanding of where the interesting data sits. And a written list of what is deliberately excluded, so nobody spends an afternoon on a system you never intended to include.
Two more are worth sending if they exist. The previous report, with the findings you believe are fixed marked as such, turns part of the new engagement into a retest and makes the comparison in the next report mean something. And a statement of the requirements the application is meant to satisfy: if you hold your developers to a published baseline such as the OWASP Application Security Verification Standard, tell the tester which level you claim, because a test against a stated requirement produces a stronger finding than a test against an assumption. For an API test the specification is not a convenience, it is the scope in machine-readable form.
Who answers the phone
Name one technical contact who can answer a question about scope or access within a working day, and check they are not on leave through the middle of the test window. Name a second route for a critical finding, because a tester who reaches customer data without authentication on Tuesday should not be holding that until the report. Agree what triggers the call and who receives it. Agree the severity language at the same time: if the report will carry CVSS scores, say which version, and say whether the score is the whole argument or one input to a rating that also weighs your exposure.
Decide whether your own detection team is told. If they are not, you get a rough second result for free in the form of what your monitoring noticed, though a test scoped for coverage is not a purple teaming exercise and should not be sold to the board as one. If they are told, you avoid an incident response call-out at midnight over traffic you commissioned. Either choice is defensible. The expensive option is not choosing, and then having the security operations team block the tester on day two while nobody senior enough to unblock them is reachable.
A readiness check to run the week before
Run the check below a week before the start date rather than the day before. A week is enough time to create accounts, raise a firewall change and find whoever owns the staging environment. A day is not, and learning that nobody has the administrator password is much cheaper on a Monday than on the morning the test begins.
If something is not ready, say so before the start date instead of hoping. Moving a test by a week costs a scheduling conversation. Starting a blocked test costs test days, and an engagement that spends its first two days on access ends up covering little more than a tool would have covered on its own, which is the difference between a test and a scan collapsing for the worst reason available.
| Item | Owner | Ready means |
|---|---|---|
| Test accounts | Application owner | Two per role, logged into by your own team, second factor settled, nothing expiring inside the window |
| Environment | Platform team | Named hosts, the build you are about to ship, representative data, restore point taken |
| Edge controls | Network team | The WAF and rate-limit decision written down, tester addresses allowlisted if the decision is to test behind it |
| Documents | Product owner | API specification, roles matrix, architecture diagram and the previous report sent |
| Contacts | Engagement owner | One technical contact and one escalation route, both reachable during the test |
| Authorisations | Legal or procurement | Written permission for anything you do not host yourself |
Preparation lead times in Dubai and Abu Dhabi
Preparation has a longer lead time here than the technical work suggests, because a test that exists to satisfy a regulator involves people outside the technical team. Banks answer to the Central Bank of the UAE. Dubai government entities and the suppliers serving them answer to the Dubai Electronic Security Center. Healthcare providers in Abu Dhabi work to ADHICS, and the UAE Information Assurance Standards published through NESA apply federally. Four regimes name security testing, and each puts a second reader behind your engagement: someone who will ask what was in scope, who authorised it and what evidence was retained. That reader shapes readiness as much as the tester does, because the answers have to be arranged before the test rather than reconstructed after it.
Two things follow. Production data inside a test environment carries handling obligations, so decide early whether the tester works against masked data or under a written handling agreement, and record which. And if you are a free-zone company in Dubai selling into a government programme, the requirements you have to meet arrive through the customer contract rather than through your own licence, which means account approvals and authorisation letters have to come from that customer. Ask for them in the week you agree the scope. In both emirates the paperwork is not the difficult part of a test, but it is the part that arrives last.
Frequently asked questions
How far in advance should we prepare for a penetration test?
Start when the scope is signed, and run a readiness check a week before the start date. Accounts, firewall changes and environment access each depend on someone outside the security team, and a week leaves room to escalate one of them. The day before does not.
Should the WAF be turned off during a penetration test?
Not turned off. Decide instead whether the tester works through it or from an allowlisted address. Testing through the edge shows what an attacker meets today, and testing behind it shows what the application itself does, which is what your developers have to fix. If the days allow, run both, unfiltered first, so findings are proved against the application and then checked against the edge.
Should we test in production or in staging?
Test where the finding will be true. Staging is a fair target when it runs the same build, the same authentication and roles, and enough data for authorisation testing to mean anything. Where it does not, every finding has to be re-argued for production, which costs more than the caution saved. If production is the target, take a restore point, agree a change freeze, and agree in writing what the tester must not touch.
How many test accounts does a penetration test need?
Two per role at minimum, each owning data of its own, plus one administrative account. A single account per role can only show that the role works, not that it is confined: proving one user cannot read another user's records needs both users to exist. Check the credentials do not expire or lock inside the test window.
