How to work with QuantumSec: from first contact to retest
By Kike Gandia · Co-Founder & CEO, OSCP
QuantumSec is a Spanish offensive security company: penetration testing, red teaming, technical audits and regulatory compliance support. This guide explains, step by step, what working with us looks like: what happens on the first call, what the proposal includes, what gets signed before starting, how the testing is run, what you receive at the end and how long each phase takes. It also covers the other way to work with QuantumSec: as a partner, if you are an agency, an MSP, an insurance broker or a consultancy that wants to offer these services to its clients.
Three ways to work with QuantumSec
Most projects come in through one of these three routes. The technical work is the same in all three; what changes is who talks to whom and who signs what.
| Route | For whom | Who contracts | What changes |
|---|---|---|---|
| Direct client | Companies and public bodies that need a pentest, an audit or support with NIS2, DORA, the ENS or ISO 27001 | The company itself, with QuantumSec | Nothing: the process in this guide, end to end |
| Through your provider | Companies whose agency, MSP, broker or consultancy already partners with QuantumSec | Depending on the model, your provider or QuantumSec | Your contact may be your usual provider, and the report may carry their brand |
| As a partner | Agencies, MSPs, brokers, consultancies and integrators | You, with your client, or your client with QuantumSec | A partnership agreement is signed first, setting the model: referral, white-label or co-selling |
If you are coming as a client, read on in order. If you are coming as a partner, the section "Working with QuantumSec as a partner" sums up the models, and the [partner program page](/en/partners/) covers them in detail.
Step 1: the first call
Everything starts with a free 30-minute call, which you book directly in the calendar on the [contact page](/en/contact/) or by emailing contacto@quantumsec.es. It isn't a scripted sales call: on the other end is a technical person who will ask you questions to understand what you need tested and why.
To make the most of it, come with these answers, even rough ones:
- What you want tested: a web application, an API, a mobile app, the internal network, Active Directory, a cloud environment, Microsoft 365 or Google Workspace.
- Why now: a launch, a client that requires it, an audit, a tender, a cyber insurance renewal, NIS2 or DORA, or a recent incident.
- How big it is: number of applications, user roles, API endpoints, IPs or sites, even in orders of magnitude.
- What your deadline is: if there is a hard date (a signing, an audit, a go-live), it's the first thing we need to know.
- What has been done before: previous pentests, scanner reports or audits.
If you're not sure what kind of test you need, that's exactly what the call is for. And if it turns out not to fit what we do, we'll tell you.
Step 2: scope and proposal within 24-48 hours
Once the scope is clear, you receive a written proposal within 24-48 hours. For projects with many assets, a second conversation or a [scoping form](/en/resources/pentesting-scoping-form/) with the exact details is sometimes needed; there's no charge for that initial analysis.
The proposal includes:
- Scope: which assets are tested and which are out, with specific URLs, IPs, applications or environments.
- Approach: black, grey or white box, and which accounts or access are used.
- Methodology: OWASP, PTES, OSSTMM or MITRE ATT&CK, depending on the type of test.
- Timeline: dates for testing, report delivery and retest.
- Deliverables: executive report, technical report, wrap-up meeting and retest.
- Fixed price: what the project costs as defined, with no open variables.
If you want a ballpark before talking, the [penetration testing cost calculator](/en/pentesting-cost-calculator/) gives indicative Spanish market ranges by test type and size. The final price is always the one in the proposal.
Step 3: what gets signed before starting
A pentest is an authorized attack. What sets it apart from a real one is precisely the written authorization, so everything is signed before the first test is launched:
| Document or agreement | What it is for |
|---|---|
| Proposal acceptance | Sets scope, timeline, deliverables and price |
| Non-disclosure agreement (NDA) | Protects the information you give us and what we find; signed before we receive any sensitive data |
| Testing authorization | Signed by whoever has authority over the systems, with the exact scope and testing windows |
| Rules of engagement | What is and isn't allowed, schedules, source IPs of the testing and emergency contacts on both sides |
| Data processing agreement | Only if the project involves processing personal data, under the GDPR |
Two details that are often forgotten. If the systems sit with a provider (a hosting company, a SaaS or a cloud with its own security testing policies), you need to confirm it allows the pentest or notify it. And if the IT team or the SOC won't be told, someone with authority needs to know, so an alert doesn't turn into an unnecessary escalation.
The general terms that apply to every project —proposal and acceptance, timelines, testing authorization and payment— are published in our [terms and conditions](/en/terms-and-conditions/).
Step 4: running the tests
The technical phase of a pentest usually takes 3 to 10 business days, depending on the scope. A red team exercise or a complex infrastructure may need longer.
How we work during that phase:
- Manual testing: we use automated tools to cover the repetitive work, but the value lies in manual exploitation and in validating the real impact of each finding. A list of scanner alerts is not a pentest.
- Nothing destructive by default: no denial-of-service or data deletion tests. If a test carries a potential risk to availability, it is agreed with you and run in a maintenance window.
- Communication during testing: you have a dedicated technical contact. If something serious comes up —a critical vulnerability exploitable from the internet, signs of a prior compromise— it is flagged through the channel agreed in the rules of engagement, without waiting for the report.
- Traceability: what was tested, from where and when is logged, so our testing can be told apart from any other activity.
The testing is carried out by a team holding OSCP, CRTO and Burp Suite Certified Practitioner certifications, remotely or on site, for clients across Spain and Europe.
Step 5: the report and the wrap-up meeting
The report is usually delivered 2-3 days after the technical phase ends. It comes as two documents for two different readers:
- Executive report: for management or whoever has to make decisions. What was tested, what real business risk there is, what is urgent and what can wait.
- Technical report: for whoever has to fix things. Each finding with its severity, evidence of how it was exploited, steps to reproduce it and a specific remediation recommendation.
Then comes the wrap-up meeting. It isn't for reading the report aloud, but for your team to ask questions: what a finding means, how to prioritize, which remediation option fits your architecture. If the report is going to a third party —an enterprise client, an insurer, an ISO 27001 or ENS auditor— we can also prepare what that third party will ask for.
Step 6: the retest
Retesting of fixes is included in all our projects. Once your team has fixed the findings, we test each one again to verify the fix works and hasn't opened another problem.
That produces the evidence that actually matters to third parties: not just what was found, but that it was fixed and that someone independent has checked it. It's what enterprise clients usually ask for in their vendor questionnaires, what ISO 27001 or ENS auditors look for, and what insurers request when underwriting a cyber policy.
The specific retest terms (when it can be requested and what it covers) are set in each proposal. The usual approach is to request it once at least the critical and high findings are fixed, so the verification doesn't need repeating.
Timeline of a typical project
For a mid-sized pentest —a web application with its API, for example— the indicative timeline is:
| Phase | Indicative timing | What it depends on |
|---|---|---|
| First call | You book it in the calendar | Your schedule |
| Proposal | 24-48 hours after the scoping call | A clear scope |
| Signing and preparation | A few days | Your internal approval process and getting access and test accounts ready |
| Technical phase | 3-10 business days | The size and complexity of the scope |
| Report | 2-3 days after the technical phase | The number of findings |
| Wrap-up meeting | After the report is delivered | Your schedule |
| Retest | Once you've fixed things | Your remediation pace |
If you have a deadline, say so on the first call: the schedule is built backwards from it. What delays a project most is rarely the technical work, but waiting for an internal signature or for access to be ready.
What we need from you
A pentest goes better, and faster, when the client has this ready:
| What | Why | When |
|---|---|---|
| A project owner | To decide on scope and receive urgent notices | From the proposal |
| A technical contact | To unblock things during testing (an account that doesn't work, a blocked IP) | During testing |
| Test accounts | In grey box, one per role to be tested; never real employee or customer accounts | Before starting |
| A defined environment | Whether production, staging or both are tested, and that staging is representative | In the proposal |
| Windows and notices | Allowed hours and who needs to know testing is under way | In the rules of engagement |
| Available documentation | API specs, diagrams or previous reports; they shorten reconnaissance | Before starting, if it exists |
None of this is required to start talking. If something is missing, we'll work it out together on the first call.
Working with QuantumSec as a partner
If you are a web agency, an MSP or IT provider, a cyber insurance broker, a consultancy or an integrator, and your clients ask you for offensive security, you can offer it without building your own team. There are three models:
| Model | Who owns the client relationship | Who invoices the client | Report branding |
|---|---|---|---|
| Referral | QuantumSec, for the project; you remain their provider for what you do | QuantumSec | QuantumSec |
| White-label or subcontracting | You | You | Yours, when the project allows it |
| Co-selling | Both, each for its own part | As set in the joint proposal | QuantumSec, for the security part |
The technical process is the one in this guide. What's added is a step beforehand: a first conversation about your clients and a written partnership agreement, with an NDA, that sets the model, the commercial terms (tailored, with no single rate card) and what happens with the end-client relationship. The [partner program](/en/partners/) page details each model and who does what.
What we don't do
Knowing where a provider's work ends saves both sides time. QuantumSec works exclusively in offensive security and the regulatory compliance that depends on it. We don't do:
- Web or application development: we find and explain the flaws and recommend how to fix them, but the fix is done by your team or your development provider.
- Day-to-day systems administration or IT maintenance.
- Insurance brokerage: in cyber insurance we handle the technical side and connect you with brokers, but we don't recommend policies.
- Reselling automated scans as if they were a pentest: if what you need is recurring vulnerability assessment, it's a different service and we call it by its name.
If what you're after is a periodic automated review, there's our [vulnerability assessment](/en/vulnerability-assessment/) service. And if the project needs one of the other pieces, the usual approach is to work alongside whoever covers it, which is exactly what the partner program is for.
FAQ
How much does it cost to work with QuantumSec?
It depends on the type of test and the size of the scope. Every project gets a fixed-price proposal before starting, with no charge for the initial analysis. For a ballpark beforehand, the penetration testing cost calculator gives indicative Spanish market ranges.
Do we have to sign a long-term contract?
No. Most of our services are fixed projects with a specific deliverable. If there is an ongoing relationship, such as recurring vulnerability assessment or a managed service, it is formalized with defined terms and a flexible exit.
Do you only work in Valencia?
No. Our headquarters are in Valencia, but we work with clients across Spain and Europe, remotely and on site. Most testing is done remotely; anything that needs a physical presence, such as a Wi-Fi audit or a red team with physical intrusion, is done on site.
Can the testing affect our production systems?
By default we avoid any action that could disrupt the service, such as denial-of-service tests or data deletion. If a test carries a potential risk, it is agreed with you and run in a maintenance window or a test environment.
What happens if you find something critical during testing?
We don't wait for the report. The rules of engagement set a channel and a contact for urgent notices, and any critical finding or sign of prior compromise is reported through it as soon as it is confirmed.
Is the retest included?
Yes, retesting of fixes is included in all our projects. The specific terms, such as when it can be requested, are set in each proposal.
Can we hire QuantumSec through our agency or MSP?
Yes. If your provider is part of the partner program, the project can come through them: in white-label, your provider remains your contact and the report can carry their brand; in referral, you contract directly with QuantumSec. If they don't partner with us yet, they can find out more on the partner program page.
Related service
partner program for agencies, MSPs, insurance brokers and consultancies