Buying the right work
Scope a security
engagement.
Start with the decision you need to make. Choose the work, inputs and evidence that would make that decision clearer.
Web3Sec is Raiders’ independent practice. Scope, availability and specialist coverage are agreed directly for each engagement.
Choose by the question
Seven useful starting points.
Several services may fit one system. Begin with the most consequential unresolved question; broader coverage can be scoped deliberately.
| Engagement & trigger | Question to resolve | Starting inputs | Useful outputs |
|---|---|---|---|
| 01Smart contract security A protocol release, accounting change, upgrade or new integration is approaching. Scope this work → | Can the scoped implementation violate the assets, permissions or economic properties the team intends to preserve? |
|
|
| 02Web & API pentesting A product, API, tenant model or administrative workflow has changed. Scope this work → | Can an actor cross an application boundary or perform an operation their role and resource relationship should prohibit? |
|
|
| 03Incident readiness & response The team needs a response exercise, an investigation plan or help interpreting a suspicious signal. Scope this work → | What is established, which decisions can contain harm, and what evidence would justify recovery? |
|
|
| 04AI & supply-chain security An agent, connector, dependency or build workflow is gaining access to sensitive data or actions. Scope this work → | Can untrusted content or code exercise authority beyond the task, release or account it should control? |
|
|
| 05Technical writing & research A security product, technical mechanism or incident needs an explanation its audience can act on. Scope this work → | Which claims can the evidence support, and what must this reader understand or do? |
|
|
| 06Security strategy & technical GTM Leadership needs to prioritize risks, resolve an architecture or release decision, or explain a security product to technical buyers. Scope this work → | Which decision matters now, what evidence is missing, and who will own the next action? |
|
|
| 07Mobile app security testing An Android or iOS release changes sensitive data handling, authentication, deep links, native integration or third-party SDK behavior. Scope this work → | Can an app, device, external entry point or connected API cross a boundary the mobile experience should preserve? |
|
|
Before work becomes a promise
Agree on what done means.
Name the decision and the boundary
Agree on the question, repositories or assets, exact versions, intended behavior, exclusions and authorized methods. Identify dependencies whose behavior is assumed rather than tested. A narrow change can still require surrounding architecture context.
Responsibilities. You identify the business decision and confirm authority over the assets. Raiders proposes the review boundary and makes omitted coverage visible.
Confirm readiness and handling
Check that builds, accounts, documentation and test data are available. Agree on access, confidentiality, evidence transfer, retention, escalation and the use of any external tooling before sensitive material changes hands.
Responsibilities. You provide approved inputs and name available technical contacts. Both sides agree on access and evidence handling; unresolved inputs remain scope assumptions.
Review evidence and manage changes
Discuss consequential observations while work is underway. Separate a confirmed finding from an unanswered question or out-of-scope concern. If code, permissions, access or the intended output changes materially, agree on the effect before extending the work.
Responsibilities. Raiders explains evidence and limitations. Your technical owner validates product context, supplies clarifications and owns implementation decisions.
Accept the output and verify the next step
Review deliverables against the agreed scope. Record the examined version, unresolved issues and any risk decisions. Define whether retesting is included, which remediation changes it covers and what further work would need separate scoping.
Responsibilities. Both sides agree on completion against the deliverables. Your decision owner accepts remaining risk and your engineering owner carries fixes into the release process.
Budget & scheduling
Estimate the work
from its drivers.
A useful proposal makes its assumptions visible. Share constraints early so the review depth and sequencing can be discussed before dates or fees are agreed.
Complexity and review depth
Trust boundaries, economic behavior, integrations, privileged workflows and the depth needed to answer the question drive effort. Source size alone is an incomplete estimate.
Input and environment readiness
A reproducible build, representative accounts, clear documentation and available test data reduce avoidable setup uncertainty. Missing or unstable inputs can change the scope and sequencing.
Coordination and constraints
Stakeholder availability, access windows, disclosure conditions, release dependencies and the need for another specialist affect how work can be scheduled.
Output and follow-up
A focused decision memo, extensive technical report, publication-ready document and repeated remediation reviews involve different work. Agree on review rounds, acceptance and retest boundaries explicitly.
Ask what is included, what depends on your team, which review rounds are planned, and how a material scope change affects the agreement. A release deadline is important context; it does not demonstrate that a system of unknown complexity fits a fixed review window.
Prepare a useful introduction
Share context first.
Agree on private access next.
Useful for the first message
- A public product link or a high-level system description
- The release, incident question or communication decision you need to resolve
- Relevant dates, current stage and the person who can agree on scope
- The type of output your engineers or decision-makers need
Agree on handling before sharing
- Private source code, architecture and internal access details
- Customer records, support captures and incident evidence
- Nonpublic findings, partner information or restricted program material
- Permitted tools, access duration, retention and any publication review
An NDA, when needed, sets confidentiality obligations. The access and handling plan still needs to specify the channel, recipients, permitted tooling, retention and deletion. Confirm that you are authorized to share third-party material. Private keys, seed phrases, passwords and production tokens are not initial scoping inputs.
For incident work, identify the authorized incident lead and the immediate decision needed before exchanging artifacts. Availability and escalation are agreed directly; Web3Sec does not present a staffed emergency intake.
Prepare a high-level project brief →Fit & specialist coverage
Choose the right depth
for the actual system.
Confirm the languages, chains, infrastructure and techniques that the proposed reviewer can cover for this scope. A contract review, application assessment, device investigation and cryptographic design review require different expertise. An independent engagement should make the coverage and any additional specialist need explicit.
Where another specialist is needed, agree on responsibility, access, confidentiality and how findings will be consolidated before work starts. A service listed here does not imply an undisclosed team or automatic coverage of every discipline. Ask which assumptions remain outside the work and who is qualified to examine them.
For writing, name the technical reviewer and publication decision-maker. For advisory, name the person who can make or accept the decision. For testing, confirm asset authority and the permitted environment. The value of the engagement depends on those responsibilities being available, not only on the final document.
A useful report helps the next person reproduce an issue, implement a change or make a documented decision. The sample finding shows one possible evidence and remediation structure. It is fictional and illustrative, not a client result or a universal report template.
- Confirm the reviewed repository, commit, deployment or document version and the assumptions attached to it.
- Turn findings into owned engineering or operational tasks with a completion condition and relevant regression coverage.
- Separate remediation work from risk acceptance; record the decision-maker, rationale and review date for issues left open.
- Provide the agreed remediation revision and test changes for retesting. A status applies to the changes actually examined.
- Reassess coverage after later features, configuration changes, new integrations or a different deployment context.
Acceptance records delivery against the agreed work. A resolved finding records the evidence examined during retesting. Neither automatically covers later code, a different deployment or an operational change outside that evidence. Keep those version and responsibility boundaries attached to the report when it is shared internally.
Discuss the decision you need to make ↗