Scoping call
Every engagement apart from incident response starts with this call. We walk your architecture with you, agree what matters most and what must stay off-limits, and recommend the kind of test that answers your question. The written scope follows by email, and there is no discovery invoice and no open-ended estimate.
Drawn to scale, minute by minute. The last slot covers the quote, the proposed start date and who signs the rules of engagement on your side.
Minutes 0 to 5 (5 minutes)
We agree what triggered the test and who the report is written for, because that decides what it must carry: an attestation letter for a customer, the scope, dates and methodology an assessor checks, or engineer-level detail only.
Minutes 5 to 15 (10 minutes)
You sketch the system on a whiteboard or a shared screen; we mark which parts become named targets in the scope and which stay out.
Minutes 15 to 25 (10 minutes)
We pick the outcomes the test will try hardest to reach, such as reading another tenant's data or triggering a payout, and the account an attacker starts from.
Minutes 25 to 33 (8 minutes)
We list every exclusion, testing window, test account and out-of-hours contact that goes into the rules of engagement, so none of it is negotiated once testing starts.
Minutes 33 to 40 (7 minutes)
The kind of test we would run, its depth in testing days, and what we would deliberately leave out and why.
Minutes 40 to 45 (5 minutes)
A fixed quote, a proposed start date and report date, the retest window, and who signs the rules of engagement on your side.
None of it needs to be polished. Missing items are fine; they become questions.
Before the 45 minutes are up.
These decide the scope and the price. Answers can be rough; knowing the questions in advance makes the call faster.
The written scope follows by email with the fixed quote from the call, for you to check. Nothing starts until you have agreed both in writing.
Signed authorisation, testing windows, traffic identifiers and escalation contacts, usually settled in one to two days.
You provision test accounts for each role and, where needed, VPN or read-only cloud access. We confirm every login works before day one, so testing days are not spent on access problems.
Daily written updates, immediate escalation of anything critical, a report with an executive summary and one entry per finding, a walkthrough with your engineers and a free retest of every fixed finding within 30 days of report delivery.
Where the attacker starts, how much they know and what they are aiming at. One scope can combine several: the sample scope further down is a grey-box web application and API test.
When: You want to know what an outsider with no knowledge and no access can achieve.
We start where any attacker starts: your domain names and public footprint. It is the most literal view of opportunistic attack, but the least efficient use of testing days, because time goes on discovery rather than depth.
When: Most product tests, when you want the best coverage for the time.
We receive an account for every role and a short architecture briefing, then test as an attacker who has signed up or phished one user. It is our default for applications, because the access-control and tenant-isolation flaws that matter most are only reachable after login.
When: Payment, identity and other high-assurance flows, or when you want root causes rather than symptoms.
Testing with source code, architecture documents and engineers on hand. We check what the code says against the running system, which finds deeper issues per day and points every finding at the line that causes it.
When: Every organisation with an internet-facing footprint, at least yearly and after significant change.
Everything reachable from the internet: exposed services, VPN and remote-access gateways, mail, DNS and forgotten hosts. We start by mapping what you expose, which is rarely identical to the asset list.
When: You want the blast radius of one compromised laptop or one phished employee.
We start inside, with a standard staff device or account as if a phishing email had worked, and measure how far that foothold reaches: Active Directory, file shares, cloud consoles and production. The report traces each step from that first account to the furthest point reached.
When: SaaS products, customer portals and any API called by partners or mobile apps.
Authenticated, role-aware testing of the application and its API surface: access control, tenant isolation, business logic, injection and session handling, with low-severity findings combined to show what they lead to together.
When: iOS or Android apps that handle payments, health data, identity documents or account access.
The binary, local storage and transport, and the backend API the app calls, tested with the app's own tokens for access-control flaws.
When: Workloads in AWS, Azure or Google Cloud, especially after fast growth or an acquisition.
An IAM-first review combined with hands-on testing: what an attacker reaches after compromising one workload, one access key or one developer laptop, and which of those paths lead to sensitive data.
When: A chat assistant, copilot, retrieval search or agent sits between users and real data or actions.
Prompt injection through documents and tool output, data leaking between users, agents acting beyond their remit and model output reaching browsers or databases unescaped, mapped to the OWASP Top 10 for LLM Applications 2026.
When: An assessor, auditor or contract expects independent testing: PCI DSS, SOC 2, ISO/IEC 27001 or a customer's security schedule.
Scoped to satisfy the requirement and still be useful. For PCI DSS that means requirement 11.4: internal and external testing at least once every 12 months and after significant change, segmentation testing where segmentation reduces scope, and retesting of what you fix. See how the main frameworks treat testing.
When: An investor, acquirer or enterprise customer wants independent evidence before signing.
A time-boxed assessment of the surfaces that matter most to the deal, reported for a non-technical reader as well as for engineers, with an attestation letter once fixes are verified. Scheduled around the deal timeline.
Every one of these is settled on the call or in the rules of engagement, before testing starts.
Every target is listed by name. Anything we discover that is not listed is reported to you, not tested, until you add it to the scope in writing.
Production gives the truest answer; staging is safer for anything that writes or deletes. Findings we could not confirm in production are labelled as such.
More knowledge buys more depth per testing day.
Testing tenant isolation needs accounts in at least two separate organisations. Seed them with test data, not real customer records.
Written into the rules of engagement. Third-party platforms are tested only where you own the account and the provider's policy allows it.
We test when your team can respond to an alert, and pause around releases and peak trading periods.
Your team can tell our traffic from a real attack, then filter it out of alerting or deliberately leave it in to test detection.
If we find something critical mid-test, we call immediately rather than saving it for the report.
Every finding you fix inside the window is retested against its original reproduction steps before it is marked closed.
The document you check and sign off after the call. Yours names your own hosts, roles and dates under the same headings.
Example with generic names and reserved addresses
No. There is no discovery invoice: the call exists so that we can give you a fixed quote, and you are under no obligation to accept it.
Someone who can describe the architecture, usually a tech lead or architect, and someone who knows why the test is happening and who will read the report. If a compliance deadline is driving the test, bring whoever owns it.
We sign your NDA before the scoping call if you ask, and work under it for the whole engagement. A high-level walkthrough is enough for scoping, so keep credentials, customer data and source code back until the rules of engagement are signed.
That is what the call is for. We ask what triggered the request and who will read the result, then recommend the smallest engagement that answers it, which is sometimes an audit or a threat model.
The quote is built from what drives effort: the number of roles, endpoints and integrations, the environments and the depth you choose. If day one reveals something materially different from what was described, such as a second application, we raise it with you before doing extra work rather than invoicing it afterwards.
Usually within two weeks of a signed scope. If a deadline cannot wait that long, raise it on the call and we will give you the earliest date we can start.
Yes. Tell us the framework and who will read the report. For PCI DSS we scope to requirement 11.4, including segmentation testing where it applies and the retest of what you fix. For SOC 2, ISO/IEC 27001 or a customer's security schedule, we scope to the systems your auditor or customer will ask about.
Do not book a scoping call. Call +972 52 613 9179 and say it is an active incident. Triage begins on the first call, remotely, before any paperwork.
A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email. Tell us what you ship and why you want it tested, and we reply within one working day with times for the call.