Step 1: The initial conversation
Most engagements start with a WhatsApp message or an email to security@simpalabs.com. There is no sales team, no discovery call gauntlet. You reach the engineers directly. In that first conversation, we establish the basics: what kind of product you are building, what systems you want tested, and what is driving the timeline. A lending platform preparing for a CBN audit has different priorities than a payment gateway that just discovered a suspicious pattern in their transaction logs.
Within 24 to 48 hours, we schedule a scoping call. This can be a 30-minute video call or a structured async exchange, depending on your preference. The goal is to define what is in scope, what approach makes sense (grey-box is our default recommendation for fintechs), and what environments and credentials we will need.
Step 2: Scoping and statement of work
After the scoping call, you receive a formal Statement of Work (SOW). This document defines the engagement boundaries explicitly: target systems, testing methodology, timeline, deliverables, escalation contacts, and pricing. There are no ambiguous clauses. If your API endpoints are in scope but your third-party payment processor is not, that distinction is stated clearly.
The SOW also specifies the testing window. We agree on start and end dates, daily update cadence, and the critical-finding escalation protocol. If we find something that could be exploited in production right now, you will know about it within hours, not at the end of the engagement.
What you need to provide
For grey-box testing, we typically need: API documentation or Postman collections, test environment access or a sandboxed production replica, test user credentials across different permission levels, and a named engineering contact for questions during testing. The more prepared your team is on day one, the less time gets spent on setup and the more time goes into actual testing. See our how to book a pentest guide for a detailed preparation checklist.
Step 3: Credentials handoff and environment verification
Before testing begins, we verify that the test environment is functional and that credentials work as expected. This sounds trivial, but roughly one in four engagements gets delayed because staging environments are misconfigured, API keys have expired, or test data has not been seeded. We run a quick validation pass and flag any blockers immediately. Testing does not start until both sides confirm readiness.
Seed realistic test data before kickoff
A test environment with two user accounts and no transaction history limits what testers can evaluate. Seed your staging environment with realistic user roles, transaction records, and edge-case data. The closer your test environment mirrors production, the more relevant the findings will be.
Step 4: The testing window
This is where the actual security testing happens. Depending on scope, a typical web application test runs one to two weeks. Mobile application testing usually takes two to three weeks because both iOS and Android binaries need static and dynamic analysis alongside the backend APIs. During this window, our engineers are manually probing your application for vulnerabilities that automated scanners cannot find: business logic flaws in payment flows, authorisation bypasses between user roles, race conditions in disbursement endpoints, and authentication chain weaknesses.
We follow a structured methodology aligned with OWASP and PTES standards, but the real value is in the manual exploration of your specific business logic. A generic scanner does not know that your loan disbursement endpoint should not allow the same BVN to trigger two concurrent disbursements.
Daily updates
You will not be left in the dark during testing. We provide daily status updates through your preferred channel, typically Slack or WhatsApp. These updates cover what was tested, what was found, and what areas are being targeted next. If a critical vulnerability is discovered, your escalation contact is notified immediately with enough detail for your team to assess whether an emergency patch is needed before the engagement concludes.
Ready to scope your next security engagement?
Start a ConversationStep 5: Draft report and walkthrough
After testing concludes, we compile a draft report within three to five business days. This report contains two layers: an executive summary for leadership, compliance officers, and investors, and a detailed technical section with every finding documented individually. Each finding includes a CVSS severity rating, proof-of-concept evidence (screenshots, request/response pairs, reproduction steps), and specific remediation guidance. For a deeper look at what goes into the report, see our article on what a good pentest report should include.
We then schedule a report walkthrough call with your engineering and security teams. This is not a slide deck presentation. We walk through each finding, explain the attack chain, answer technical questions, and help your developers understand what needs to change at the code level.
Step 6: Remediation guidance
Every finding comes with actionable remediation steps. Not "improve input validation" but specific guidance like "implement object-level authorisation checks on the /api/v1/transfers/{id} endpoint using the authenticated user's tenant ID as a filter." We also prioritise findings by business impact so your team knows what to fix first. Critical and high-severity issues that affect payment flows or expose customer data get addressed before medium-severity configuration gaps.
If your team has questions during remediation, we remain available. The engagement does not end the moment the report lands in your inbox.
Step 7: Retest and final deliverables
Once your team has addressed the findings, we retest. This is a targeted verification pass, not a full re-engagement. We re-run the specific attack scenarios that originally produced findings and confirm whether the fixes hold. Findings that pass retest are marked as resolved. Findings that remain exploitable stay open with updated notes.
The final deliverable package includes: the updated technical report with retest results, an executive summary, a remediation roadmap, a retest certificate confirming verified fixes, and a letter of attestation. That attestation letter is the document you hand to CBN auditors, enterprise clients, and investors. It confirms that a structured penetration test was conducted and that identified findings were remediated and verified. For the complete list of documents, read our guide on documents to demand after a penetration test.
What makes this process different
Most security vendors hand you a PDF and disappear. What you get from Simpa Labs is a working relationship that extends through remediation. We are not trying to find as many low-severity findings as possible to pad a report. We are trying to find the vulnerabilities that would actually damage your business, help you fix them, and verify the fixes hold. That is the difference between a penetration test and a compliance checkbox.
We work exclusively with fintechs. That means we understand PCI DSS requirements, CBN audit expectations, and NDPA/NDPR compliance natively. We do not need your team to explain what an OTP bypass means in the context of a mobile money platform.
Related reading
Blog: How a Simpa Labs pentest works · Is Simpa Labs right for payment startups? · Security audit before launch
Guides: How to book a pentest · Pentest report explained · Pentest pricing guide
Services: Penetration testing · API security · Architecture review