Skip to main content

How to Prepare for a Security Assessment Estimate

This document helps teams prepare for a security assessment estimate. Thorough preparation enables the technical team to evaluate the scope efficiently and provide an accurate estimate without unnecessary delays. Please review the checklist below and prepare the required materials in advance to help the technical team estimate the time and effort needed.

Language requirement

Please provide all documentation in English.

Smart Contract Audit​

  • Access to the code repository or deployment addresses
  • Commit hash or branch to be audited
  • Scope definition (in-scope contracts or files)
  • Out-of-scope components (e.g., mocks, scripts, vendored libraries)
  • Testing framework (e.g., Foundry, Hardhat, Brownie)
  • Architecture and technical documentation (whitepaper, specifications, or README)
  • Target blockchain networks
  • For forked code: original project, upstream repository, and upstream commit hash

Blockchain Protocol Audit​

  • Protocol overview, target Layer 1 or Layer 2 networks, and development stage
  • Access to code repositories, with target branches, commit hashes, and in-scope modules
  • Out-of-scope components and dependencies
  • For forked protocols: upstream repository, base version or commit, and summary of changes
  • Architecture documentation, technical specifications, and system diagrams
  • Security model, trust assumptions, and validator or permission design
  • Custom or modified subsystems (e.g., consensus, P2P networking, VM, state management, or bridges)
  • Custom or modified cryptographic libraries and dependencies
  • Build, deployment, and local testnet instructions, along with test suites and coverage
  • Security concerns or areas requiring special attention

Web Application & API Penetration Testing​

  • List of domains and subdomains

  • API documentation (e.g., OpenAPI/Swagger specification or Postman collection)

    For example:

    • GET /api1/abc/xyz
    • POST /api1/abc/xyz
    • PUT /api1/abc/xyz
    • DELETE /api1/abc/xyz

  • Number of in-scope API operations (endpoint + HTTP method)

  • User roles and test accounts (e.g., User, Admin, Backoffice)

Mobile Application Penetration Testing​

  • Target platforms (iOS, Android, or both)

  • Access method:

    • APK and/or IPA file
    • TestFlight, Play Store, or App Store link

  • List of domains and subdomains

  • API documentation (e.g., OpenAPI/Swagger specification or Postman collection)

    For example:

    • GET /api1/abc/xyz
    • POST /api1/abc/xyz
    • PUT /api1/abc/xyz
    • DELETE /api1/abc/xyz

  • Number of in-scope API operations (endpoint + HTTP method)

  • User roles and test accounts (e.g., User, Premium User)

Secure Code Review​

  • Access to the code repository
  • Target branch and commit hash
  • In-scope repositories, modules, and files
  • Out-of-scope components
  • Programming languages and frameworks
  • Application overview, critical workflows, and integrations
  • Architecture and technical documentation

Desktop Application Penetration Testing​

  • Target platforms and OS versions (Windows, macOS, Linux)

  • Application installer or installation/access instructions

  • Application framework (e.g., .NET, Java, Electron)

  • In-scope components and exclusions (client, backend/API, local services)

  • API documentation (e.g., OpenAPI/Swagger specification or Postman collection), if in scope:

    For example:

    • GET /api1/abc/xyz
    • POST /api1/abc/xyz
    • PUT /api1/abc/xyz
    • DELETE /api1/abc/xyz

  • Number of in-scope API operations (endpoint + HTTP method)

  • User roles and test accounts (e.g., User, Admin, Backoffice)

Browser Extension Penetration Testing​

  • Target browsers (Chrome, Firefox, Edge, Safari)

  • Extension version and installation package or store link

  • Extension overview, critical workflows, and integrations

  • In-scope components and exclusions (extension, backend/API, companion desktop application)

  • Source code repository and build instructions, if available

  • API documentation (e.g., OpenAPI/Swagger specification or Postman collection), if in scope:

    For example:

    • GET /api1/abc/xyz
    • POST /api1/abc/xyz
    • PUT /api1/abc/xyz
    • DELETE /api1/abc/xyz

  • Number of in-scope API operations (endpoint + HTTP method)

  • User roles and test accounts (e.g., User, Admin, Backoffice)

Cloud & Infrastructure Assessment​

  • Cloud provider (AWS, GCP, Azure, etc.)
  • In-scope accounts, projects, subscriptions, and regions
  • In-scope environments (production, staging, development)
  • In-scope services and assets, with approximate counts (e.g., EC2, EKS, S3, RDS, Lambda, GKE, Cloud SQL, Kubernetes clusters, load balancers, IAM)
  • Architecture diagram

Network Penetration Testing​

  • Assessment type (external, internal, or hybrid)
  • IP addresses and subnets in scope
  • Approximate number of active hosts
  • Access method (VPN, bastion, or SSM), if required
  • Available test accounts and privilege levels, if applicable
  • Network diagram, if available
  • API testing requirements, if applicable (scoped separately)
  • Out-of-scope systems and testing restrictions

Threat-Led Penetration Testing (TLPT)​

  • Primary assessment objective and success criteria

    For example:

    • Gain access to the internal network
    • Compromise a standard user account
    • Obtain privileged or administrator access
    • Access a critical system or sensitive data
    • Test security monitoring and incident response

  • Critical business services and workflows to assess

  • Key security concerns and scenarios of interest, if known

  • Starting access and assumed attacker privileges

  • In-scope assets and approximate counts (e.g., 2 applications, 2 internal subnets, 20 servers, and 1 Active Directory domain)

  • In-scope identities and target roles

  • Out-of-scope assets, activities, and testing restrictions

Red Teaming​

  • Primary assessment objective and success criteria

    For example:

    • Determine whether an external attacker can access critical systems or sensitive data
    • Evaluate security monitoring and incident response

  • Approximate number of internet-facing domains and subdomains

  • Companies, brands, or business units in scope

  • Main public websites or domains associated with the scope

  • Critical business services, systems, and data to protect

  • Permitted objectives and target systems after initial access

  • Scope exclusions and operational restrictions

  • Whether the security monitoring team will be informed, and any notification requirements

Proof of Reserves​

  • Organization overview, business activities, and audit frequency
  • In-scope reserve assets, blockchain networks, and approximate number of addresses
  • Wallet architecture (single-signature, multisignature, or smart contracts) and staked assets
  • Method for demonstrating address ownership (e.g., signed messages or test transactions)
  • Customer liability data format, approximate number of balance records, and access to a replica database for verification
  • Customer liability verification method, if applicable (e.g., Merkle tree generation, zero-knowledge (ZK) proofs, or a custom cryptographic proof mechanism)

AI Red Teaming​

  • System overview, intended use cases, and priority risk scenarios (e.g., jailbreaks, data leakage, agent over-privilege)
  • In-scope models (providers, versions, hosting), input/output modalities, and inference endpoints
  • Agent architecture, tool/API execution capabilities, permission model, and MCP integrations
  • RAG workflows, connected vector databases, and knowledge sources
  • Existing guardrails, system prompts, content filters, and safety policies
  • Testing environment access, test accounts, and any constraints or rate limits

CyberSec Advisory​

  • Project overview, technology stack (smart contracts, dApps, protocols, infrastructure), and development stage
  • Security goals, priorities, and success criteria for the engagement
  • Preferred advisory model (advisor-led or client-led) and requested weekly capacity
  • Architecture documentation, known security concerns, and existing security controls
  • Expected advisory activities (e.g., architecture reviews, threat modeling, secure SDLC guidance, or audit coordination)
  • Key milestones, audit roadmap, and target launch dates

Managed DevSecOps​

  • Project overview, technology stack, and development stage (DeFi/Web3 or Traditional Finance)
  • Cloud providers (AWS, GCP), in-scope accounts, projects, regions, and environments
  • In-scope services and assets, with approximate counts, and architecture diagrams
  • Existing infrastructure-as-code, repositories, CI/CD platforms, and approximate number of pipelines
  • Current infrastructure and pipeline setup, known issues, and required improvements
  • Expected responsibilities (e.g., infrastructure setup, migration, pipeline management, release support, monitoring, patching, or recovery)
  • Release frequency, upcoming milestones, and planned longer-term work
  • Required support hours, on-call coverage, maintenance windows, and response expectations
  • Existing access controls, secrets management, and key-management arrangements
  • For DeFi/Web3 projects: target networks, contract deployment and upgrade workflows, signing arrangements, and supporting off-chain infrastructure
  • Applicable compliance requirements (ISO 27001, SOC 2, GDPR, PCI DSS, or CCSS key management)
  • Designated customer decision maker responsible for priorities, task order, approvals, and overall service direction
  • Scope exclusions, operational restrictions, and dependencies on customer or third-party teams

Cybersecurity Compliance​

  • Target framework(s) or regulation (e.g., ISO 27001, ISO42001, SOC 2, CCSS, DORA, VARA, CMA, ADGM, BMA, AIUC-1) and the regulator or certifying body involved, if any
  • Engagement type: Implementation support (we help you prepare) or Third-Party Assessment (independent audit or regulator-required report)
  • Framework-specific level or type, if known (e.g., CCSS Level 1/2/3; SOC 2 Type 1 or Type 2 and Trust Services Criteria)
  • Business activities in scope (e.g., exchange, custody, brokerage, stablecoin issuance, payments)
  • Key management model (third-party custodian such as Fireblocks or BitGo, in-house, or hybrid), if digital assets are held
  • Existing certifications or audit reports (e.g., ISO 27001, SOC 2, ISAE 3402) and recent penetration test or smart contract audit reports
  • Target deadline or licensing milestone, and any regulator correspondence or findings to address

Let’s secure the decentralized world together. 🚀